\documentclass[a4paper,10pt]{article}
\usepackage[utf8x]{inputenc}
\usepackage[cm]{fullpage}

%opening
\title{Course Diary - Entry \#8\\
475 Advanced Topics in Software Engineering}
\author{Eli Gutin \texttt{eg08}, \\ Michael Kwan \texttt{mk08}, \\ John Wong \texttt{jw808} }

\begin{document}

\maketitle

\section{Three key points from the lecture}

\begin{itemize} 
\item{Developing software from components is an idea that it is more difficult
to achieve in practice than it is to conceptualize. These principals, however, have
been applied to complex problem domains such as electronic circuit design. The key idea
is the whole system is comprised of components and modules. Components provide an interface to each other at the component-level and then when composed together form a module which performs a well-defined role. Modules themselves are plugged together to do the job required. If modules could be reduced to the size of components then this would give an almost fractal model which becomes easy to work with.}
\item{DI is a useful technique in structuring software systems. The responsibility of
instantiating objects and establishing dependencies is removed from the objects themselves and placed
in a separate "configuration". In OO code this effectively gets rid of the use of the \texttt{new} keyword
buried deeply in the code. Doing this at the highest level in your code gives ease and flexibility of configuration. A common term for this is a container whose job it is to wire together and manage the lifecycles of objects. It is a popular approach that has been achieved through the Spring, Guice and other frameworks.}
\item{The approach arose from a rebellion against EJB (Enterprise Java Beans). The improvements that were
achieved were the ability to unit test each class by completely decoupling their logic into POJOs (Plain Old Java Objects). With this and AOP (Aspect Oriented Programming) each object became much simpler and
only contained the core business logic. AOP itself is a way of separating and modularising the cross-cutting concerns in a typical application (e.g. Logging, transactions and profiling). Among DI approaches there are some disagreements/variability in how much of the application configuration resides in the code and how much in separate (usually XML) configuration. As well as that some frameworks (e.g. Spring) have greater integration with the JEE stack.}
\end{itemize}
\section{Related Reading}
We read the following article by Martin Fowler \texttt{http://martinfowler.com/articles/injection.html}. \\
There he discusses the same problem that was addressed in the lecture namely that instantiating objects inside another one (for the former ones to be used as services) is inherently bad practice since you're automatically
coupling the client to the service. In this article Martin lists approaches that solve this problem, namely, the Service Locator and Dependency Injection patterns. He concludes that the service locator, while being simpler to understand because the code is making explicit calls to the locator every time it requires the service, still has disadvantages compared to DI. With DI you can clearly see the dependencies without having to look everywhere in 
the code for calls to the service locator. As well as, this unit testing is much easier with DI as you construct your object in the test case with the mocked out dependencies that it needs. Our only disagreement is that dependency injection
is not really that difficult to grasp especially when you understand that the configuration is happening at a much higher level. Nevertheless, in our opinion, we agree with Martin that DI is to be preferred.
\section{Similar Past Projects}
\subsection{Mike's experience}
The \texttt{Spring} framework is something that was used heavily in the company I worked at during my industrial placement. During that time, I only used the annotations method of wiring up beans to variables in my code. I thought 
doing this was great for the readability of the code, allowing readers to focus on what was going on, assuming appropriate instantiation of collaborators and dependencies. Using the framework also ensured the code I wrote was well 
decoupled. I quickly realised if I did not write well decoupled code, the beans became a nightmare to create.

\subsection{Eli's experience}
I have experience in using the Spring framework. It made it easier to write and test code, gave me the freedom to swap in different implementations and have greater control over how my domain model was 
configured and structured. As well as that, their JDBC abstraction layer was really handy and I even explored the AOP features (which I didn't find as useful) because of the proxying implementation of it which didn't work when I called methods from inside the same object.
\subsection{John's experience} 
Throughout many group or individual software developments I have done, I have noticed how important it is to have a mindset of seeing object classes as components
and to avoid as many natural connections as possible in between them. Doing so, the code produced will be more portable, compatible and readable.
Since I understood this in the first year, I have a habit of planning the responsibilities for each object class and the formats of all the input and output for each function
before proceeding to development in a software project.

\section{Tutorial Exercise Goals}
The main objective of this exercise is to refactor a house alarm system such that it can configure up to 3 different rooms through 3 separate main methods. 
To do this, first we needed to break the dependencies between object classes such as \texttt{Room} and \texttt{IntruderDetector}, \texttt{IntruderDetector} and \texttt{ReallyLoudSiren}.
In order to prove the system's functionality, we were required to implement dummy objects such as \texttt{DummySiren}, \texttt{TestSensor} and \texttt{TestLight}
for printing out each room's configuration.

\section{Main Challenges}
To ensure inversion of control, we needed to inject dependencies and collaborators via either constructor or setter injection. It was tough to find the right balance, since at some point it comes down to a personal preference. We faced 
the issue that having all dependencies injected in the constructor resulted in huge constructors. We also considered the implicit information about a class that a constructor hints at. It is expected that a constructor creates a 
valid object (all necessary field instances are set) as well as implicitly provides information about immutability of fields through a lack of setters in the class for parameters set through the constructor. This creates a problem for 
cases when you want to modify some dependency at runtime. Using only setter injection means that incomplete objects are potentially instantiated and this puts greater responsibility on the caller to have a intimate knowledge of 
the collaborators. Ultimately, we wanted to keep immutability of constructor assigned field instances but allow flexibility for change. We eventually opted for a mix, with fields which were unlikely to be changed being assigned immutably 
in the constructor and having setters available for other fields.

\section{Approaches}
Our approach to this tutorial was to extract all object instantiations out of classes to all happen in the \texttt{main}. We then altered the constructor parameters accordingly to allow this. We took note of which fields we felt might be changed and 
added setters for these. One example is the \texttt{Sensor} object, which needed a setter for its \texttt{Light}. However, instead of creating a setter for sensors in rooms, we actually created \texttt{addSensor}/\texttt{deleteSensor}/\texttt{getSensors} 
methods because we believe it is a realistic future extension that a room have multiple sensors. For the wiring of test objects into the system, we extracted the methods of the concrete classes into interfaces. This was fairly straightforward with the 
exception of \texttt{ReallyLoudSiren}. The interface and use of \texttt{ReallyLoudSiren} as a singleton throughout the code meant we had to make \texttt{DummySiren} a singleton too. This is a debatable design choice, but the interface allows easy 
refactoring should we decide to change our mind.

\section{Feedback on the lecture/exercise}
We felt that this particular lecture was lacking in some ways in comparison to the previous ones. We felt some content in the first part of the lecture was too detailed and we thought they could be discussed more concisely. 
We also thought having one hour of tutorial in between two lectures was not ideal as people might not maintain the fresh memory of the information perceived from the previous half of the lecture.

As for the exercise, we thought that it was relatively trivial since the code-base was small and simple, which meant we could grasp it immediately and pursue our goal quickly.
\end{document}
